Skip to content

chore: add .npmrc with supply chain protection#244

Open
wheeljackz wants to merge 1 commit intomainfrom
chore/supply-chain-protection
Open

chore: add .npmrc with supply chain protection#244
wheeljackz wants to merge 1 commit intomainfrom
chore/supply-chain-protection

Conversation

@wheeljackz
Copy link
Copy Markdown
Collaborator

Summary

Adds .npmrc with supply chain protection settings:

  • save-exact=true — pins dependencies to exact versions instead of semver ranges, preventing unexpected updates
  • min-release-age=7 — quarantines newly published packages for 7 days, blocking typosquatting and fast-publish supply chain attacks (like the axios@1.14.1 incident)

Test Plan

  • Verified npm install still works with the new settings
  • No functional changes to application code

- save-exact=true: pin exact versions instead of semver ranges
- min-release-age=7: quarantine newly published packages for 7 days

Ref: axios supply chain attack (axios@1.14.1 / plain-crypto-js@4.2.1)
Copy link
Copy Markdown
Collaborator Author

@wheeljackz wheeljackz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left two supply-chain review notes inline. The main gaps are that min-release-age is not effective on the repo's current npm toolchain, and save-exact only affects future dependency additions so the repo is still mostly operating on existing semver ranges.

Comment thread .npmrc
# - min-release-age: quarantine newly published packages for 7 days
# (blocks typosquatting & fast-publish supply chain attacks like axios@1.14.1)
save-exact=true
min-release-age=7
Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

min-release-age looks like the right control, but it is not effective on the current toolchain used here yet. In this checkout, npm --version is 11.8.0, and npm warns Unknown ... config "min-release-age"; npm's own rollout notes say this feature landed in CLI 11.10.0+. As written, the PR message says we are quarantining new packages, but today's CI/dev installs will silently ignore this line. I would either pin npm to >=11.10.0 (for example via Volta plus CI setup) or avoid claiming this protection is active yet.

Comment thread .npmrc
# - save-exact: pin to exact versions instead of semver ranges
# - min-release-age: quarantine newly published packages for 7 days
# (blocks typosquatting & fast-publish supply chain attacks like axios@1.14.1)
save-exact=true
Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small but important scope gap: save-exact=true only changes how future npm install/add commands write new entries. It does not pin the dependencies already in package.json, and this repo still has many ^ ranges checked in. That means the comment above overstates the current protection level. Could we either normalize the existing dependency ranges in this PR/follow-up, or reword the comment/PR description to say this only affects newly added packages?

Copy link
Copy Markdown
Collaborator Author

@wheeljackz wheeljackz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Validated the new .npmrc against npm's current config/install docs and this repo's pinned toolchain. Two points came up: one compatibility issue that will affect contributors on the documented Node version, and one follow-up hardening suggestion if we do move to the newer npm feature set.

Comment thread .npmrc
# - min-release-age: quarantine newly published packages for 7 days
# (blocks typosquatting & fast-publish supply chain attacks like axios@1.14.1)
save-exact=true
min-release-age=7
Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

min-release-age was added in npm CLI 11.10.0. This repo still pins Node 24.1.0 via Volta, and Node 24.1.0 ships npm 11.3.0, so contributors on the documented toolchain will get Unknown project config "min-release-age" before install. I’d either bump the baseline Node/npm version first, or hold this setting until the repo standard is on npm 11.10+.

Comment thread .npmrc
@@ -0,0 +1,6 @@
# Supply chain protection
Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we do move the repo to npm 11.10+ for supply-chain hardening, I’d consider adding allow-git=none here in the same pass. npm’s own install docs recommend it because git dependencies can override the git executable via nested .npmrc files, and I couldn’t find any git-based deps in package.json or package-lock.json, so it looks like a safe default for this project.

Copy link
Copy Markdown
Owner

@zainfathoni zainfathoni left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found one issue in this change and left it inline.

Comment thread .npmrc
# - min-release-age: quarantine newly published packages for 7 days
# (blocks typosquatting & fast-publish supply chain attacks like axios@1.14.1)
save-exact=true
min-release-age=7
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this enables the protection yet. The release-age gate was added in npm CLI 11.10.0+, but the repo currently pins node 24.1.0 in package.json and my local npm here is 11.8.0, which warns Unknown project config "min-release-age" when reading this file. In that toolchain the install still proceeds without the intended guardrail, so we probably need to pin/upgrade npm first (or defer this until the repo guarantees an npm version that supports it).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants